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ABSTRACT 

Multithreaded  programs  coordinate  their  interaction 
through  synchronization  primitives  like  mutexes  and 
semaphores,  which  are  managed  by  an  OS-provided 
resource  manager.  We  propose  algorithms  for  the  auto¬ 
matic  construction  of  code- aware  resource  managers  for 
multithreaded  embedded  applications.  Such  managers 
use  knowledge  about  the  structure  and  resource  usage 
(mutex  and  semaphore  usage)  of  the  threads  to  guarantee 
deadlock  freedom  and  progress  while  managing  resources 
in  an  efficient  way.  Our  algorithms  compute  managers  as 
winning  strategies  in  certain  infinite  games,  and  produce 
a  compact  code  description  of  these  strategies.  We  have 
implemented  the  algorithms  in  the  tool  Cynthesis.  Given 
a  multithreaded  program  in  C,  the  tool  produces  C  code 
implementing  a  code-aware  resource  manager.  We  show  in 
experiments  that  Cynthesis  produces  compact  resource 
managers  within  a  few  minutes  on  a  set  of  embedded 
benchmarks  with  up  to  6  threads. 
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1.  INTRODUCTION 

Embedded  and  reactive  software  is  often  implemented  as  a 
set  of  communicating  and  interacting  threads.  The  threads 
most  commonly  rely  on  primitives  such  as  mutexes  and 
counting  semaphores  to  coordinate  their  interaction,  to  en¬ 
sure  the  atomic  execution  of  critical  code  regions,  and  to 
ensure  that  shared  data  structures  are  correctly  accessed. 
These  mutexes  and  semaphores  (which  we  collectively  term 
resources)  are  managed  independently  of  the  application 
code.  In  this  paper,  we  propose  the  automated  construc¬ 
tion  of  code-aware  managers  for  resources.  Such  managers 
use  their  knowledge  of  the  thread  structure  and  resource 
usage  to  manage  resources  in  an  efficient  and  deadlock-free 
fashion. 

The  simplest  resource  managers,  found  in  the  implemen¬ 
tation  of  just  about  any  thread  library,  use  the  most  liberal 
of  policies:  grant  a  resource  whenever  it  is  available.  The  lib¬ 
erality  of  this  policy  creates  the  possibility  of  deadlocks:  the 
classical  example  is  when  thread  1  requests  (and  is  granted) 
a  mutex  A,  and  thread  2  requests  (and  is  granted)  a  mu¬ 
tex  B.  If  the  next  requests  are  for  mutex  B  from  thread  1, 
and  for  mutex  A  from  thread  2,  deadlock  ensues.  Writing 
software  that  is  deadlock-free  under  such  a  simple  resource 
management  policy  is  a  difficult  and  error-prone  task  [21, 
11].  Monotonic  locking  [20]  ensures  deadlock  freedom,  at  the 
price  of  imposing  additional  bookkeeping  on  the  program¬ 
mer.  Monotonic  locking  also  cannot  be  extended  to  counting 
semaphores,  where  there  is  no  notion  of  a  particular  thread 
“holding”  a  resource.  Priority  ceiling  uses  information  on 
the  set  of  locks  used  by  each  thread  to  guarantee  deadlock 
freedom  [3].  Like  monotonic  locking,  however,  priority  ceil¬ 
ing  cannot  cope  with  counting  semaphores.  Furthermore, 
in  the  setting  that  we  study  in  this  paper,  when  all  threads 
have  the  same  priority  and  need  to  get  a  fair  share  of  CPU 
time,  priority  ceiling  is  a  most  restrictive  policy:  it  allows  at 
most  one  thread  to  hold  mutexes  at  any  given  time.  Other 
algorithms,  such  as  the  banker’s  algorithm  [20],  rely  on  a 
manual  analysis  of  the  resources  needed  for  given  tasks,  and 
again  do  not  cover  code  with  semaphores. 

We  present  an  automatic  static  technique  to  synthesize 
code-aware  resource  managers  for  multithreaded  embedded 
applications  that  guarantee  deadlock  freedom  while  man¬ 
aging  resources  in  a  liberal  and  efficient  way.  Rather  than 
synthesizing  the  whole  scheduler,  we  focus  on  the  resource 
policy,  i.e.,  the  part  of  the  scheduler  responsible  for  grant¬ 
ing  resources,  depending  on  the  underlying  OS  scheduler  to 
resolve  the  remaining  scheduling  choices.  Our  formulation 
does  not  require  special  programmer  annotations  or  code 
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hile  (1)  { 

if  (exp)  { 

mutex.lock  (  a)  ; 
mutex.lock  (  b  )  ; 

//  critical  region 
mutex.unlock  (  b  )  ; 
mutex _unlock(a)  ; 

}  else  { 

mutex.lock  (  a)  ; 
mutex.lock  (  c  )  ; 

//  critical  region 
mutex _unlock(  c)  ; 
mutex_unlock(a)  ; 

} 


(a)  Thread  1 


while  (1)  { 

mutex.lock  (  6  )  ; 
mutex_lock(a)  ; 

//  critical  region 
mutex.unlock  (  a  )  ; 
mutex _unlock(  b)  ; 


} 


(b)  Thread  2 


Figure  1:  Two  fragments  of  C  code. 
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structures,  nor  any  change  in  programming  style.  Hence,  it 
is  directly  applicable  to  existing  bodies  of  code. 

To  illustrate  the  advantages  of  code-aware  managers,  con¬ 
sider  the  threads  of  Figure  1.  Thread  1  and  Thread  2  can 
lead  to  a  deadlock  under  a  standard,  most  liberal  resource 
manager.  On  the  other  hand,  the  code-aware  manager  we 
construct  is  able  to  differentiate,  in  Thread  1,  between  the 
requests  for  the  mutex  a  occurring  on  the  then  and  else 
branches  of  the  if  statement  (during  code  analysis,  informa¬ 
tion  about  the  location  of  resource  manager  calls  is  added  to 
the  calls  themselves).  When  Thread  1  holds  mutex  a,  and 
Thread  2  requests  mutex  b,  the  request  is  granted  if  Thread  1 
is  in  the  else  branch,  and  denied  otherwise.  Similarly,  when 
Thread  2  holds  the  mutex  b,  and  Thread  1  requests  the  mu¬ 
tex  a,  the  request  is  granted  if  Thread  1  is  in  the  else  branch, 
and  denied  otherwise.  In  all  cases,  the  code-aware  manager 
guarantees  deadlock  freedom  while  managing  resources  in  a 
fair  and  liberal  manner. 

We  focus  on  the  problem  of  ensuring  fair,  deadlock-free 
progress  of  all  the  threads  composing  the  embedded  applica¬ 
tion;  priorities  will  be  dealt  with  in  future  work.  We  assume 
that  threads  are  correct,  except  possibly  for  their  resource 
interaction:  for  instance,  we  do  not  guarantee  progress  if  a 
thread  holding  a  mutex  enters  an  infinite  loop  (no  resource 
manager  guarantees  progress  under  these  conditions).  In 
other  words,  we  focus  on  the  resource  management  prob¬ 
lem,  rather  than  on  the  software  verification  problem. 

We  formulate  the  scheduling  problem  as  a  game  between 
the  manager  and  the  threads,  where  the  goal  for  the  man¬ 
ager  Is  to  avoid  deadlocks  while  ensuring  that  all  threads 
make  progress.  A  winning  strategy  in  this  game  provides  a 
code-aware  manager  that  guarantees  progress  for  all  threads 
at  run  time.  In  this  game,  the  manager  has  two  sources 
of  antagonism:  first,  there  is  the  non-determinism  of  each 
thread  (such  as  the  if  of  Thread  1);  second,  the  OS  scheduler 
chooses  which  thread  to  run  when  more  than  one  is  ready. 
Treating  both  sources  of  antagonism  in  a  purely  adversar¬ 
ial  way  would  lead  to  the  conclusion  that  most  systems  are 
doomed  to  starvation.  Rather,  we  include  a  detailed  analy¬ 
sis  of  what  kind  of  fairness  assumptions  are  needed  to  obtain 
a  more  realistic  model  of  the  system.  This  analysis  is  not 
present  in  some  recent  work  on  code-aware  schedulers  [17, 
16],  a  circumstance  that  prevents  those  schemes  from  ad¬ 
dressing  the  problem  of  progress  (or  absence  of  starvation). 


Figure  2:  Cynthesis  tool  flow:  from  the  source  code 
of  an  embedded  application,  to  the  executable  ap¬ 
plication  with  its  code-aware  resonrce  manager. 


which  is  a  major  concern  in  the  present  paper.  We  argue 
that  this  analysis  is  also  necessary  to  extend  the  scope  of 
the  synthesis  to  address  quality  of  service  concerns. 

To  achieve  compact,  yet  fair,  managers,  we  consider  win¬ 
ning  strategies  that  may  be  randomized,  that  is,  scheduling 
decisions  may  use  lotteries  over  available  moves;  the  strate¬ 
gies  ensure  progress  and  fairness  with  probability  1.  We 
provide  efficient  algorithms  that  compute  winning  strategies 
from  the  source  code  in  quadratic  time,  while  accounting  for 
scheduler  and  thread  fairness.  We  then  take  a  closer  look 
at  the  interaction  between  the  resource  manager  and  the 
underlying  operating  system  scheduler,  and  we  show  how 
the  standard  strategy  obtained  by  solving  the  game  can  be 
made  more  efficient  in  a  real-world  resource  manager.  We 
show  how  the  strategies  can  be  represented  compactly  using 
HDDs,  and  we  discuss  how  to  implement  the  resource  man¬ 
ager  so  that  it  is  compact  in  terms  of  code  size  as  well  as 
efficient  to  execute  at  run-time. 

The  tool  Cynthesis.  We  have  implemented  these  algo¬ 
rithms  in  the  tool  Cynthesis.  Our  tool  takes  as  input  a 
multithreaded  application  written  in  C,  and  produces  code 
for  a  custom  resource  manager  for  the  application.  The 
Cynthesis  tool  flow  is  illustrated  in  Figure  2.  First,  Cyn¬ 
thesis  identifies  the  threads  composing  the  embedded  ap¬ 
plication,  and  extracts  from  each  thread  a  resource  interface 


which  summarizes  the  resource  usage  (mutexes,  semaphores) 
of  the  thread.  These  resource  interfaces  are  then  merged 
into  a  joint  interface,  and  game-theoretic  methods  are  used 
to  generate  a  code-aware  resource  manager  from  the  joint 
interface;  this  code-aware  resource  manager  also  consists  of 
C  code.  While  generating  the  resource  interfaces,  Cynthe- 
SIS  annotates  the  code  of  the  embedded  application,  so  that 
it  can  communicate  with  the  resource  manager.  The  result¬ 
ing  annotated  application,  and  resource  manager,  can  then 
be  compiled  and  linked  to  obtain  the  complete  embedded 
application.  Currently,  Cynthesis  produces  code  for  the 
the  eCos  embedded  operating  system  [10];  the  tool  can  be 
easily  retargeted  to  other  operating  systems. 

We  have  applied  the  tool  to  a  set  of  small  multithreaded 
embedded  applications  with  up  to  six  threads.  In  each  case, 
Cynthesis  produced  the  custom  resource  manager  within  a 
few  minutes,  and  the  resource  manager  could  be  compactly 
represented  using  BDD-based  data  structures  with  a  few 
hundred  nodes.  We  have  also  applied  Cynthesis  to  a  larger 
case  study,  described  in  Section  5,  consisting  in  a  multi¬ 
threaded  program  implementing  an  ad-hoc  network  protocol 
for  mobile  robots.  In  this  case  study,  Cynthesis  correctly 
identified  and  prevented  a  subtle  deadlock  that  was  present 
in  the  original  application. 

Related  work.  In  closely  related  work,  [17,  16]  study  the 
synthesis  of  code-aware  managers  for  Java.  The  focus  is 
deadlock  avoidance,  and  as  mentioned  earlier,  the  question 
of  progress  (absence  of  starvation)  is  not  addressed. 

The  problem  of  deadlock  prevention  has  been  extensively 
studied  in  at  least  three  different  fields:  databases,  operating 
systems,  and  flexible  manufacturing  systems.  In  the  latter 
field  [9,  18,  1,  14,  12,  15],  it  is  assumed  that  a  Petri  Net 
model  is  constructed  by  hand.  Also,  most  of  these  works 
deal  with  processes  that  are  terminating  and/or  determin¬ 
istic.  In  contrast,  our  approach  and  tool  rely  on  the  auto¬ 
mated  analysis  of  software,  and  we  deal  in  detail  with  the 
issues  arising  from  code  abstraction  and  interaction  with 
operating-system  schedulers.  Further,  the  use  of  random¬ 
ization  to  generate  efficient  schedulers  has  not  been  studied. 

Static  compiler  techniques  have  been  used  in  high  perfor¬ 
mance  thread  packages  to  improve  response  time  through 
better  scheduling  [24],  however,  the  problem  of  resource  in¬ 
teraction  and  deadlock  has  not  been  studied.  Finally,  dead¬ 
lock  detection  and  prevention  methods  from  transactional 
databases  do  not  apply  in  our  setting,  since  our  applications 
do  not  have  transactional  semantics  and  rollback. 

Paper  organization.  In  Section  2,  we  define  thread  re¬ 
source  interfaces  and  joint  interfaces,  and  outline  how  such 
interfaces  are  extracted  from  the  code  of  the  embedded  ap¬ 
plication.  Section  3  covers  the  game-theoretical  techniques 
used  to  generate  code-aware  resource  managers.  This  sec¬ 
tion  presupposes  some  knowledge  of  game  theory,  and  may 
be  skipped  by  readers  interested  in  forming  a  general  idea  of 
the  tool  Cynthesis.  Section  4  explains  how  to  adapt  the  re¬ 
source  managers  obtained  via  game-theoretical  methods  to 
the  characteristics  of  the  runtime  environment  of  an  embed¬ 
ded  application,  obtaining  managers  that  are  more  efficient 
in  practice.  Finally,  Section  5  describes  the  tool  Cynthe¬ 
sis,  as  well  as  the  examples  and  case  studies  that  have  been 
analyzed  with  it. 


2.  THREAD  RESOURCE  INTERFACES 

2.1  Resources 

A  resource  is  a  non-sharable,  reusable  quantity.  For  our 
purposes,  a  resource  x  is  an  integer- valued  variable  together 
with  a  set  of  actions  {wx^-,gxT,rx\}  on  x.  Intuitively,  these 
actions  correspond  to  communications  between  the  threads 
that  manipulate  the  resource  and  the  resource  manager,  and 
have  the  following  meaning: 

•  Wx^-'.  a  thread  requests  the  resource  x  (“want  x”). 

•  QxT-  the  resource  manager  grants  the  resource  a;  to  a 
thread  (“get  a:”). 

•  rx\'-  the  thread  releases  the  resource  x  (“release  a;”). 

Given  a  set  R  of  resources,  the  set  of  actions  on  R  is 
Acts[R]  =  {wa;!,  Pa;?,  Ta;!  |  3:  G  7?}  U  {e}.  The  output  actions 
over  R  are  given  by  Acts‘^[R\  =  {wx\,rx\  ]  a;  G  i?}  U  {e}, 
and  correspond  to  communication  from  the  thread  to  the 
resource  manager.  In  addition,  we  have  a  special  action  e 
which  is  needed  in  Dehnition  3  below.  The  input  actions 
over  R  are  given  by  Acts^[R\  =  {pa;?  ]  x  G  R},  and  corre¬ 
spond  to  communication  from  the  resource  manager  to  the 
thread.  We  consider  two  types  of  resources:  mutexes  and 
(counting)  semaphores.  A  mutex  is  a  resource  that  takes 
value  in  {0, 1}  and  starts  from  the  initial  value  1;  a  mutex 
can  only  be  released  by  the  same  thread  that  acquired  it 
(as  in  POSIX).  A  semaphore,  on  the  other  hand,  can  be 
initialized  to  any  integer,  and  can  be  released  and  acquired 
without  constraints,  except  that  its  value  can  never  become 
negative. 

2.2  Thread  Interfaces 

We  model  the  behavior  of  threads  by  thread  interfaces. 
Thread  interfaces  model  only  the  resource  manipulation  as¬ 
pect  of  threads,  and  abstract  out  all  data  manipulation. 

Definition  1.  A  thread  interface  I  =  (R,  S,  E,  A)  con¬ 
sists  of  a  set  R  of  resources,  a  finite  control-flow  graph  {S,  E) 
with  E  C  S  X  S ,  an  initial  state  s'"'*  G  S,  and  an  action  la¬ 
bel  \  :  E  —>  Aets[R]  \  {e}  mapping  each  edge  to  a  resource 
action,  such  that 

•  each  Wx^.  edge  leads  to  a  state  whose  only  outgoing  edge 
is  labeled  with  gxT ; 

•  each  Pa;?  edge  starts  from  a  state  whose  incoming  edges 
are  all  labeled  with  Wx\. 

Intuitively,  the  conditions  on  a  thread  interface  guarantee 
that  a  “want”  action  is  immediately  followed  by  the  cor¬ 
responding  “get”  action;  moreover,  a  “get”  action  has  no 
siblings.  We  say  that  a  state  s  is  final  if  it  has  no  suc¬ 
cessors.  For  s  £  S,  let  Isucc{s)  =  {t  G  S'  j  (s,t)  G 
E  A  A(s,t)  G  Acts^[R]}  be  the  set  of  input  successors  of  s, 
and  let  Osucc{s)  =  {t  G  S  |  {s,t)  £  E  A  X{s,t)  £  Acts^\R]} 
be  the  set  of  output  successors  of  s.  We  carry  subscripts 
over  to  components,  so  that  an  interface  E  will  consist  of 
{Ri,Si,Ei,sfl'^,\i)-,  similarly,  we  carry  subscripts  to  Isucc 
and  Osucc. 

Example  1.  Consider  the  POSIX  interface  for  mutexes  with 
functions  mutex_lock(x)  and  mutex_unlock(x) .  Each  call 
mutex_lock(x)  is  represented  by  the  pair  of  actions  Wx\  and 


(a)  Thread  interface  1  (b)  Thread  inter¬ 

face  2 

Figure  3:  The  thread  interfaces  corresponding  to 
the  code  in  Figure  1. 

QxT',  a  (nonblocking)  call  mutex_unlock(x)  is  represented 
by  the  action  r^;!.  Similarly,  for  a  counting  semaphore  y, 
the  function  sem_wait(y)  corresponds  to  the  two  actions 
Wy\  and  Qyl,  and  the  function  sem_post(y)  corresponds  to 
the  release  action  ry\.  For  example,  our  tool  extracts  the 
resource  interfaces  of  Figure  3  from  the  code  in  Figure  1.  I 

2.3  Systems 

Syntax.  Given  a  set  R  of  resources,  a  resource  valuation  is 
a  function  u  :  R  r-f  'N  mapping  each  resource  to  a  natural 
number  value.  For  a  valuation  v  and  x  &  R,  we  denote  by 
vlx  ~  k]  the  valuation  obtained  from  u  by  assigning  the 
value  fe  G  N  to  x.  A  system  is  a  set  of  resources,  an  initial 
resource  valuation  of  the  resources,  and  a  tuple  of  (a  fixed 
number  of)  thread  interfaces. 

Definition  2.  A  system  is  a  tuple  T  =  (i?,  (7i, . . . ,  /„)), 

consisting  of  a  set  R  of  resources,  a  mapping  :  R  N 
assigning  an  initial  value  to  each  resource,  and  of  n  >  0 
thread  interfaces  We  require  that  Ri  C  R,  for 

1  <i  <n,  and  that  if  x  €  R  is  a  mutex,  i^’^(x)  =  1. 

Semantics.  Given  a  system,  we  can  define  its  semantics 
using  a  jo^nt  interface,  obtained  by  constructing  the  product 
of  the  interfaces,  annotated  with  the  values  of  the  resources 
at  the  states.  The  joint  interface  models  the  execution  of  a 
multithreaded  system  on  a  single  processor. 

Definition  3.  Given  a  system  T  =  {R,u^,  (7i, . . .  ,In)),  its 
joint  interface  is  a  tuple  Mx  =  (7?,  S',  7?,  A,  0),  where  R 
is  as  in  T,  and: 

•  S=  x(77^N); 


•  E  C  S  X  S,  and  X  :  E  Acts[R],  6  :  E  {0, . . . ,  n} 
are  defined  as  follows.  Let  s  =  (si, . . . ,  s„,  o)  G  S;  we 
have  {s,t)  G  E,  X{s,t)  =  a,  and  9{s,t)  =  i  iff  there  is 
s'i  G  Si  such  that  (si,s')  G  Ei,  Ai(si,s')  =  a,  and  for 
t  =  {si,...,  Si-1,  s'i,  Si+i,  ...,s„,  v')  we  have: 

[resource  grant]  if  a  =  g^T,  then  v{x)  >  0  and  v'  = 
v[x  ~  v{x)  —  1]; 

[resource  request]  if  a  =  wA,  then  v'  =  v;  and 
[resource  release]  if  a  —  rA,  then  v'  =  i^[x  :=  v{x)  E 
1];  further,  if  x  is  a  mutex,  then  v{x)  =  0. 

Moreover,  let  s  be  a  state  that  has  no  successors  according 
to  the  above  rules.  Then,  we  add  a  self-loop  {s,  s)  £  E  and 
we  set  A(s,  s)  =  e  and  9{s,  s)  =  0. 

Let  s  £  S  and  s  =  (si, . . . ,  s„,  v);  for  all  i  =  1, . . .  ,n,  we 
set  loci{s)  =  Si.  We  let  Osucc,  Isucc  refer  to  Mx,  and  for 
1  <  i  <  n,  we  let  Osucd,  Isucd  refer  to  L. 

In  Mx,  edges  labeled  with  the  special  action  e  are  a  technical 
addition,  used  to  ensure  that  all  finite  paths  can  be  extended 
to  infinite  ones. 

The  portion  of  the  joint  interface  Mx  that  is  reachable  from 
its  initial  state  may  not  be  finite,  as  the  value  of  re¬ 
sources  could  grow  beyond  bounds.  Of  course,  if  all  re¬ 
sources  are  mutexes  (which  take  values  0  and  1),  the  state 
space  is  finite.  In  general,  a  coverability  tree  algorithm  for 
Petri  nets  can  check  for  boundedness,  but  this  check  is  ex¬ 
pensive. 

Theorem  1.  Let  Mx  ~  {R,  S,  E,  ,  X,d)  be  the  joint  in¬ 
terface  of  a  system  T.  The  problem  of  deciding  whether 
the  portion  of  S  that  is  reachable  in  {S,  E)  is  finite  is 
EXPSPACE-hard. 

In  the  following,  we  only  consider  systems  T  such  that  the 
reachable  portion  of  Mx  is  finite.  In  our  tool  Cynthesis  we 
avoid  solving  the  question  of  whether  the  portion  of  the  joint 
interface  reachable  from  the  initial  state  is  finite.  Rather, 
we  simply  take  as  input  the  maximum  value  to  consider 
for  any  semaphore;  this  value  is  usually  well  known  to  the 
programmer.  If  we  find  a  reachable  state  where  the  value 
of  a  semaphore  is  greater  than  this  maximum,  we  stop  and 
report  the  problem. 

3.  THE  SCHEDULING  GAME 

In  this  section,  unless  otherwise  noted,  we  consider  a  fixed 
system  T  =  (77,  ,  (Ii, . . . ,  In)),  which  gives  rise  to  a  joint 

interface  Mx  =  (77,  S,  E,  A,  6). 

A  joint  interface  evolves  by  the  interaction  between  three 
entities:  the  threads,  the  resource  manager,  and  the  sched¬ 
uler.  From  a  given  state,  if  there  are  any  outgoing  edges 
labeled  by  input  actions,  the  resource  manager  can  choose 
to  follow  one  of  them:  this  corresponds  to  granting  a  re¬ 
source  to  a  thread.  Once  the  input  edge  has  been  followed 
(and  the  resource  granted),  the  resource  manager  still  re¬ 
tains  control  at  the  destination  state.  From  a  given  state,  if 
there  are  any  edges  labeled  by  output  actions  that  leave  the 
state,  the  resource  manager  can  also  elicit  to  return  control 
to  the  threads.  At  this  point,  which  output  action  occurs 
next  depends  on  two  factors.  The  underlying  operating- 
system  scheduler,  using  its  own  policy  (such  as  time-sharing 
with  round  robin),  selects  which  of  the  ready  threads  exe¬ 
cute  on  the  CPU.  In  addition,  each  thread  has  its  own  inter¬ 
nal  nondeterminism,  which  determines  which  output  action 


the  thread  generates  next.  Thus,  we  identify  three  types  of 
nondeterminism  in  the  joint  interface. 

1.  Resource  manager  nondeterminism,  due  to  the  re¬ 
source  manager  choosing  an  input  edge,  or  choosing 
to  wait  for  an  output  action. 

2.  Inter-thread  nondeterminism,  due  to  the  operating- 
system  scheduler  resolving  thread  interleaving. 

3.  Intra-thread  nondeterminism,  which  determines  which 
of  several  possible  output  actions  a  thread  will  do. 

Resource  manager.  The  goal  of  the  resource  manager  is 
to  ensure  that  all  threads  progress,  unless  they  terminate. 
In  order  to  define  the  goal,  we  introduce  the  following  pred¬ 
icates  over  edges  of  Mi:  for  1  <  *  <  n,  the  predicate 
progress i  is  true  over  an  edge  (s,  t)  £  E  ii  9{s,  t)  =  i,  and  the 
predicate  final^  is  true  over  an  edge  (s,  t)  £  E  if  the  thread 
i  is  in  a  final  state  in  s.  Using  temporal  logic  notation,  and 
considering  that  final ^  is  equivalent  to  D final the  goal  can 
be  written  as  a  generalized  Biichi  condition  over  the  edges: 

n 

^goai  _  yy  aO{progress^  final fi). 

i=l 

Our  aim  is  to  synthesize  a  resource  manager  that  satisfies 
this  goal.  In  order  to  model  accurately  the  resource  manager 
synthesis  problem,  we  make  the  following  fairness  assump¬ 
tions  over  the  other  two  types  of  nondeterminism. 

Inter-thread  nondeterminism.  We  assume  that  the  un¬ 
derlying  operating  system  scheduler  is  fair:  more  precisely, 
we  assume  that,  if  a  thread  is  infinitely  often  ready  to  exe¬ 
cute,  it  will  make  progress  infinitely  often.  We  introduce  a 
predicate  ready for  1  <  i  <  n,  which  is  true  over  an  edge 
(s,  t)  £  E  iS  (i)  (s,  t)  is  labeled  with  an  output  action,  and 
(ii)  there  is  (s,  t')  £  E  with  9{s,  t')  =  i.  Intuitively,  (i)  means 
that  the  resource  manager  decided  to  let  the  scheduler  sched¬ 
ule  some  thread,  and  (ii)  means  that  thread  i  was  among  the 
threads  that  could  have  generated  the  next  output.  With 
this  notation,  the  fairness  assumption  on  the  scheduler  is: 

n 

^mter  _  ^  j)  . 

i=l 

Intra-thread  nondeterminism.  Assuming  that  intra¬ 
thread  nondeterminism  is  resolved  in  an  arbitrary  way  may 
easily  lead  to  declaring  the  manager  synthesis  problem  to 
be  infeasible.  In  fact,  whenever  a  thread  can  execute  a 
loop  while  holding  a  resource,  the  arbitrary  resolution  of 
intra-thread  nondeterminism  introduces  the  possibility  that 
the  loop  never  terminates.  In  practice,  a  reasonable  as¬ 
sumption  is  that  intra-thread  nondeterminism  is  resolved 
in  a  (strongly)  fair  fashion:  if  each  choice  is  presented  in¬ 
finitely  often,  each  choice  outcome  will  follow  infinitely  of¬ 
ten.  Such  fairness  entails  loop  termination.^  For  all  threads 
1  <  i  <  n,  all  M,  u  €  Si,  and  all  {s,t)  £  E,  we  in- 

def 

troduce  the  predicates  from'“{s,t)  =  {loCi{s)  =  u)  and 

^Recall  that  our  goal  is  to  schedule  correct  software,  rather 
than  to  perform  software  verification. 


takefi'’ {s,t)  ((/oci(s)  =  u)  A  (loci(t)  =  v)).  The  fair¬ 

ness  assumption  for  intra-thread  nondeterminism  can  then 
be  written  as 

n 

=  /\  /\  {aOfrom^  ^  aotakefi^). 

i=l  u^Sj,  vGOsucci{u) 

3.1  Stochastic  Games 

We  base  the  synthesis  of  the  resource  manager  on  stochas¬ 
tic  games.  As  we  will  see  in  detail  later,  we  use  prob¬ 
abilities  both  to  approximate  the  above  types  of  nonde¬ 
terminism,  and  to  be  able  to  generate  manager  strategies 
that  are  memoryless,  but  that  may  require  randomization 
[4].  Given  a  finite  set  A,  we  denote  by  Distr(A)  the  set  of 
probability  distributions  over  A.  For  d  £  Distr(A)  we  let 

Supp(d)  =  {a  £  A  \  d{a)  >  0}.  Given  a  €  A  we  denote  by 

(5(a)  £  Distr(A)  the  probability  distribution  that  associates 
probability  1  with  a,  and  0  to  all  other  elements  of  A.  We 
also  denote  by  Uniform{A)  the  probability  distribution  that 
associates  probability  1/|A|  to  every  element  of  A. 

Definition  4.  A  two-player  game  G  = 

{S,  Moves,  Fi,  r2,  r,  (())  consists  of  a  set  of  states  S,  of  a  set 
of  moves  Moves,  of  two  mappings  ri,r2  :  S  \  0 

associating  to  each  state  s  and  player  i  £  {1,  2}  the  set  of 
moves  ri(s)  that  player  i  can  play  at  s,  a  (probabilistic) 
destination  function  t  :  S  x  Moves'^  1-^  Distr(S'),  which 

associates  with  each  s  £  S  and  mi  £  ri(s),  m2  £  r2(s), 

a  probability  distribution  r(s, mi, m2)  over  the  successor 
state.  Finally,  the  winning  condition  (f>  is  a  measurable 
subset  of  5“ . 

For  i  £  {1,2},  we  say  that  G  is  an  i-Markov  decision 
process  (i-MDP)  [8]  if  |r3_i(s)|  =  1  at  all  s  G  S;  1- 
MDPs  are  also  called  simply  MDPs.  A  strategy  for  player 
i  £  {1,2}  in  a  game  G  =  {S,  Moves,V\,V2,T)  is  a  map¬ 
ping  TTi  :  5'”''  Distr(Moi;es),  such  that  for  all  a  £  S* 
and  s  £  S,  we  have  T:i{as){m)  >  0  implies  m  G  ri(s). 
We  denote  by  IIi,  112  the  set  of  strategies  for  players  1 
and  2  respectively.  Once  the  strategies  tti  and  712  are  fixed, 
the  game  is  reduced  to  an  ordinary  stochastic  process,  and 
the  probabilities  of  all  measurable  events  (which  include  all 
w-regular  properties  [22])  are  defined  (see  e.g.  [13]).  We 
say  that  a  state  s  G  S  is  winning  if  there  is  tti  G  Ffi 
such  that,  for  all  772  G  112,  we  have  Pr^^ ’’^^  (((>)  =  1.  As 
we  use  randomized  strategies,  winning  with  probability  1 
is  the  natural  notion  of  winning.  We  denote  by  Win{G) 
the  set  of  winning  states.  A  winning  strategy  is  a  strat¬ 
egy  that  wins  from  all  winning  states,  that  is,  a  strategy 
TTi  G  Hi  such  that,  for  all  s  £  Win{G)  and  all  112  G  112, 
we  have  {(f>)  =  1.  The  size  of  a  game  is  defined  by 

IGl  =  E.esE^ieriW  I  Supp(r(s,  mi,  m2)) |. 

3.2  The  Scheduling  Game 

Since  our  aim  is  to  derive  strategies  that  resolve  resource 
manager  nondeterminism,  we  formulate  the  resource  man¬ 
ager  synthesis  problem  as  a  game  played  on  the  joint  in¬ 
terface  by  the  resource  manager  against  a  team  consisting 
of  the  threads  and  the  scheduler.  Again,  unless  otherwise 
noted,  we  refer  to  a  system  T  —  {R,  ,  (Ji, . . . ,  /„))  which 

gives  rise  to  a  joint  interface  Mi  =  {R,  S,  E,  s'“*.  A,  9). 

Definition  5.  The  two-player  game  corresponding  to  a  sys¬ 
tem  X  consists  of  a  tuple  G^  =  {S,  Moves,  ri,T2,T,<j}‘^), 


where  Moves  =  5  U  {1}  and  4>^  =  (4"''=’'  A  4"'''“)  ^ 

The  sets  of  moves  for  player  1  (representing  the  resource 
manager)  and  player  2  (representing  the  inter  and  intra¬ 
thread  nondeterminism)  are  as  follows,  for  all  s  €  S: 

•  If  Osucc{s)  7^  0,  then  ri(s)  =  Isucc{s)  U  {_L}  and 
r2(s)  =  Osucc(s). 

•  If  Osucc(s)  =  0,  then  ri(s)  =  Isucc{s)  and  r2(s)  =  {-L}. 
The  destination  function  is  given  by  the  following  rules, 
where  *  represents  a  wildcard,  and  s  G  S: 

•  Fort  G  Isucc{s),  we  have  T{s,t,*)  =  5{t); 

•  fort  G  Osucc{s),  we  have  r(s,-L,i)  =  5{t). 

The  manager  synthesis  problem  can  thus  be  phrased  as  the 
problem  of  finding  a  winning  strategy  in  G^.  We  say  that 
the  system  is  schedulable  if  G  Win{G^).  One  can  see 
that  this  goal  is  upward- closed,  so  that  memory  less,  but  ran¬ 
domized,  strategies  suffice  to  win  the  game  [4]. 

3.3  Practical  Solution  of  the  Scheduling  Game 

The  best  known  algorithms  to  compute  a  winning  strategy 
in  G^  take  time  exponential  in  the  winning  condition,  and 
in  our  case,  the  size  of  the  winning  condition  is  proportional 
to  the  sum  of  the  sizes  (numbers  of  states)  of  all  thread  in¬ 
terfaces  in  T  [23].  Thus,  this  approach  leads  to  an  inefficient 
algorithm.  Instead,  we  show  that  we  can  exploit  the  spe¬ 
cial  structure  of  the  joint  interface  and  solve  the  synthesis 
problem  in  a  more  efficient  way,  consisting  of  two  steps.  We 
consider  two  simplified  versions  of  G^: 

1.  A  game  G^  ®,  resulting  from  resolving  all  intra-thread 
nondeterminism  in  G^  in  a  purely  randomized  fashion. 

2.  An  MDP  G^'^ ,  resulting  from  resolving  both  the  intra¬ 
thread  and  the  inter-thread  nondeterminism  in  G^  in 
a  purely  randomized  fashion. 

We  show  that  we  can  construct  in  quadratic  time  in  |G^| 
a  winning  strategy  for  the  MDP  G^  ®  which  is  also  a  win¬ 
ning  strategy  of  the  game  G^  ®.  We  show  that  this  winning 
strategy,  under  many  cases  of  practical  importance,  is  also 
a  winning  strategy  for  the  original  game  G^.  In  all  cases, 
we  show  that  it  is  possible  to  check  efficiently  whether  the 
strategy  for  game  G^  ®  works  also  for  G^  —  and  in  our  ex¬ 
perience,  this  has  been  always  the  case  in  the  examples  we 
have  studied  so  far. 

Definition  6.  Given  the  game  G^  = 

(S,  Moves,  the  games  G^'®  = 

[S,  Moves' and  G^'® 

{S, Moves, Vi, V'2, t" are  obtained  as  follows.  We 
have  Moves'  =  Moves  U  {!,..., n},  i))^'®  = 
and  The  functions  T'2,t'  and  ^2^^"”  coincide 

with  r2,'r,  except  that: 

•  For  all  s  £  S  such  that  |Osmcc(s)|  >  1,  we  let  r2(s)  = 
{i  I  G  r2(s) .  9{s,  t)  =  i},  and  for  i  G  r2(s),  we  let 
r'(s,T,i)  =  Uniform{{t  G  P2(s)  |  0{s,t)  =  i}). 

•  For  all  s  £  S ,  we  let  T'f  =  {-L},  and  we  let 
r"(s,T,T)  =  Uniform{Osucc{s)) . 

First,  we  show  how  to  construct  the  most  liberal  winning 
strategy  for  game  G*^  ®;  informally,  this  is  the  strategy  that, 
among  the  winning  ones,  plays  with  positive  probability  the 
largest  possible  sets  of  moves. 


A  memory  less  strategy  tt  G  IIi  gives  rise  to  a  graph 
{S,E.,r),  where  =  {{s,t)  \  w(s)(t)  >  0  or  7r(s)(T)  > 
OandA(s,t)  G  Acts‘^[If\].  A  maximal  end  component 
(MEG)  of  G*^  ®  is  a  maximal  subgraph  (G,  F)  of  (S',  E)  such 
that:  there  is  a  memory  less  strategy  tt  such  that  G  is  a 
closed  (no  outgoing  edge)  and  strongly  connected  compo¬ 
nent  of  (S,  E^),  and  such  that  F  =  {{s,t)  £  E,,  \  s  £  G}  [6]. 
We  say  that  thread  k  is  finished  in  a  state  s  if  lock{s)  is  final 
in  Ik-  Notice  that  if  a  thread  k  is  finished  at  some  state  of 
a  MEG,  it  is  finished  at  all  states  of  the  MEG.  We  say  that 
a  MEG  (G,  E)  is  fair  iff,  for  every  thread  1  <  fc  <  n,  either 
k  is  finished  in  G,  or  there  is  (s,  t)  £  F  with  6{s,  t)  =  k. 
Let  W  be  the  union  of  all  sets  of  states  belonging  to  fair 
end  components.  It  can  be  shown  that  a  state  is  winning 
in  G^  ®  iff  it  can  reach  W  with  probability  1  [4];  we  denote 
by  Win{G^'^)  the  set  of  winning  states  of  G^  ®.  By  the  re¬ 
sults  of  [6,  7],  this  set  can  be  computed  in  time  quadratic  in 

|Gi-®|. 

The  most  liberal  winning  strategy  tt*  for  G*^  ®  is  the 
strategy  that  selects  uniformly  at  random  among  moves  of 
player  1  that  lead  only  to  winning  states.  Precisely,  for 
s  £  Win{G^'^),  we  let  tt*{s)  =  Uniform{{m  G  ri(s)  |  Vt  G 
S.{t" {s,m,  lS){t)  >  0  ^  t  £  Win{G^'^))}).  tt*  is  arbitrarily 
defined  on  states  s  £  S  \  Win{G^'^). 

Theorem  2.  The  strategy  tt*  is  winning  in  G*^  ®,  and  can 
be  computed  in  time  0(|G^  ®P). 

In  the  next  section,  we  present  some  technical  lemmas,  that 
are  later  used  to  show  the  relationships  between  the  different 
versions  of  the  scheduling  game. 

3.4  Properties 

In  order  to  argue  that  tt*  is  winning  not  only  in  G*^  ®,  but 
also  in  G*^  ®,  we  need  to  develop  some  properties  of  tt*  and 
Mi.  First,  we  state  a  simple  property  of  Mi. 

Lemma  1.  In  Mi,  there  is  no  loop  made  entirely  of  input 
edges,  and  there  is  no  loop  made  entirely  of  output  edges. 

Proof.  The  first  statement  is  due  to  the  fact  that  each 
input  edge  decreases  the  value  of  a  resource.  The  second 
statement  is  due  to  the  fact  that  resource  requests  (wa,!)  are 
immediately  followed  by  an  input  edge,  and  resource  releases 
(rA)  increase  the  value  of  a  resource.  ■ 

We  now  show  that,  in  Mi,  input  and  output  moves  com¬ 
mute,  as  they  are  independent.  In  the  following,  we  write 
s  ^  t  to  signify  that  (s,  t)  £  E,  \{s,  t)  =  x  and  9{s,  t)  =  i. 

i 

Lemma  2.  For  all  s,  51,52  €  5,  if  s  — ^  5i  and  s  — ^  52, 

«  j 

Q,l  (39 

then  there  is  t  £  S  such  that  S2  — 3  t  and  si  — >  t. 

i  3 

Proof.  First,  notice  that  i  ^  j,  as  input  edges  have  no 
siblings  in  their  respective  thread  (see  Definition  1).  Second, 
the  value  of  each  resource  in  si  is  at  least  as  much  as  it  is 
in  s.  Thus,  there  is  a  state  t  such  that  si  — >  t.  In  S2,  the 

3 

value  of  a  certain  resource  is  lower  than  it  is  s.  However, 
output  edges  are  not  affected  by  the  value  of  the  resources, 
so  there  is  a  state  t'  such  that  S2  t' ,  and  by  construction 

i 

of  Ml,  we  have  t  =  t' .  ■ 

The  following  lemma  states  an  equivalent  commutativity 
property  for  outputs  belonging  to  different  threads. 


Figure  4:  Outputs  cannot  link  winning  states  to  los¬ 
ing  ones. 

a'  /3' 

Lemma  3.  For  all  s,5i,S2  €  5,  if  s  — ^  si  and  s  — S2, 

i  3 

Q!  ^  /3  ^ 

with  i  7^  j,  then  there  ist  G  S  such  that  $2  — ^  t  and  si  t. 

i  3 

Proof.  Since  output  edges  can  either  decrease  resource 
usage  (in  the  case  of  resource  release  actions),  or  leave  re¬ 
source  usage  unchanged  (in  the  case  of  resource  request  ac¬ 
tions),  a!  will  still  be  enabled  from  S2,  and  /3!  will  be  enabled 

a’ 

from  si;  moreover,  by  construction  of  Mi,  we  have  S2  — ^  t 

i 

and  Si  — >  t  for  the  same  t.  I 

3 

The  following  lemma  shows  that,  in  an  edge  labeled 

with  an  output  cannot  connect  a  winning  state  to  a  losing 
state. 

Lemma  4.  Let  s  €  Win{G^'^)  and  s  t.  Then,  t  G 
Mn(Gi'®). 

Proof.  Suppose  that,  starting  from  s,  we  keep  following 
winning  inputs,  as  long  as  there  is  a  winning  input  in  the 
current  state.  By  Lemma  1,  we  must  eventually  reach  a  state 
Sm-i  that  has  no  winning  inputs.  By  repeated  applications 
of  Lemma  2,  the  output  a\  is  still  enabled  in  Sm-i. 

Summarizing,  as  illustrated  in  Figure  4,  we  can  find  a  path 
o  =  ssi  ■  ■  ■  Sm  such  that  (i)  all  states  in  a  are  winning,  (ii) 
all  edges  in  a  except  the  last  one  are  labeled  with  inputs, 
and  (in)  the  last  edge  (sm-i,  Sm)  is  labeled  with  a!. 

Again  by  repeated  applications  of  Lemma  2,  from  t  we 
can  mimic  the  path  a,  by  taking  similar  input  edges,  finally 
reaching  Sm-  We  obtain  the  conclusion  that  t  can  reach  the 
winning  state  Sm  be  means  of  input  edges  only.  So,  t  itself 
is  a  winning  state.  I 

In  the  following,  we  say  that  a  path  is  in  Win{G^'^)  to  mean 
that  it  is  a  path  in  G^  ®  made  entirely  of  winning  states.  We 
now  introduce  a  binary  relation  “C”  over  the  set  of  winning 
states  of  G^  ®.  For  all  s,s'  G  Win{G^'^),  let  s  C  s'  if  and 
only  if  there  is  a  path  a  in  IFm(G^  ®)  that  goes  from  s 
to  s'  using  only  output  edges.  The  following  lemma  shows 
that  if  s  C  s'  and  an  input  edge  is  winning  from  s,  the 
corresponding  input  edge  from  s'  is  also  winning. 

Lemma  5.  Let  s  C  s'.  For  all  t  G  lTm(G^  ®)  such  that 
s  t  there  is  t'  G  Win{G^'^)  such  that  s'  t'  and 

i  i 

t  G  t'. 

Proof.  Let  a  be  a  path  from  s  to  s'  in  Win{G^'^)  that 
contains  only  outputs  edges.  By  repeated  applications  of 
Lemma  2,  we  can  take  a  similar  path  a'  from  t,  leading  to  a 
state  t'  such  that  t  G  t' .  Moreover,  by  construction  s'  t' . 

i 

By  applying  Lemma  4  to  all  edges  in  a'  we  obtain  that,  since 
t  is  winning,  t'  is  also  winning.  ■ 


The  following  lemma  will  be  instrumental  in  showing  that 
TT*  is  a  winning  strategy  also  in  G^  ®. 

Lemma  6.  There  isp  >  0  such  that,  for  all  s  G  lTm(G^  ®), 
if  in  Win{G^'^)  there  is  an  acyclic  path  from  s  to  a  state 
s',  then  using  tv*  in  G^'®,  for  all  player  2  strategies,  with 
probability  at  least  p,  starting  from  s  the  game  reaches  a 
state  t'  such  that  s'  G  t'. 

Proof.  Let  p  be  the  path  from  s  to  s';  the  proof  is  by 
induction  on  the  length  of  p.  Fix  an  arbitrary  strategy  of 
player  2.  For  \p\  =  0,  the  result  trivially  holds.  As  induction 
hypothesis,  assume  that  there  is  a  path  p  from  s  to  s'  in 
lTm(G^  ®),  and  assume  that  using  tt*  in  G^  ®  we  can  reach 
from  s  a  state  t'  such  that  s'  G  t'  with  positive  probability. 
Let  o  be  the  sequence  of  output  actions  leading  from  s'  to 
t' ,  and  let  6  be  the  path  from  s  to  t'.  We  will  show  that,  if 
we  prolong  p  by  one  step,  reaching  s",  then  we  can  prolong 
0  by  0  or  more  steps,  obtaining  a  path  0"  to  t",  such  that 
s"  G  t" ,  and  such  that  9"  is  followed  with  positive  bounded 
probability  in  G^  ®.  Notice  that,  due  to  Lemma  3,  outputs 
of  different  threads  commute.  Hence,  we  can  consider  the 
ordering  in  ct  restricted  to  outputs  belonging  to  the  same 
thread.  Equivalently,  rather  than  a,  we  can  reason  about  the 
collection  of  sequences  of  output  actions  {o'i}i=i..n,  where 
Oi  represents  the  sequence  of  actions  of  thread  i  along  a. 
There  are  then  three  cases,  depending  on  the  step  s'  s''-. 

•  Assume  that  s'  s" ,  for  some  a  and  i  G  {1, . . . ,  n}. 

i 

By  Lemma  5,  there  is  also  a  winning  step  t'  t" , 

i 

and  a  path  from  s"  to  t"  that  uses  the  sequence  of 
output  actions  a.  As  tt*  takes  this  step  with  positive 
probability,  this  leads  to  the  result. 

•  Assume  that  s'  s" ,  for  some  a  and  i  G  {1, . . . ,  n}; 

i 

assume  also  that  a  does  not  appear  in  ai.  By 
Lemma  3,  from  t' ,  the  same  output  a  is  enabled,  so 
that  TT*  will  play  with  positive  probability  action  _L, 
and  in  G^  ®  some  output  (3  will  occur.  If  /3  belongs 
to  thread  i,  then  with  positive  probability  (according 
to  the  randomized  resolution  of  intra-thread  nondeter¬ 
minism)  it  must  he  (3  =  a,  and  the  destination  state 
t"  will  be  related  to  s"  again  by  a.  If  (3  does  not  be¬ 
long  to  thread  i,  we  add  (3  to  a.  By  Lemma  3  we  have 
that  output  a  Is  still  enabled  from  the  destination  state 
after  /?,  so  that  tt*  will  again  play  T  from  the  destina¬ 
tion  with  positive  probability.  Eventually,  an  output 
belonging  to  thread  i  will  occur,  as  by  Lemma  1  there 
cannot  be  an  infinite  path  consisting  entirely  of  output 
actions. 

•  Assume  that  s'  s",  for  some  a  and  i  G  {1, . . . ,  n}; 

i 

assume  also  that  a  appears  in  ai.  Then,  with  posi¬ 
tive  probability  (dne  to  the  resolntion  of  inter-thread 
nondeterminism),  a  will  be  the  first  action  of  ai.  We 
remove  a  from  ai,  obtaining  a  shorter  a';  we  have  that 
s"  G  t' ,  and  s"  and  t'  are  related  by  a' . 

The  existence  of  a  constant  bound  p  >  0  derives  from  the 
fact  that  the  length  of  p,  and  the  size  of  a,  are  bounded,  as 
is  the  number  of  ways  in  which  intra-thread  nondeterminism 
can  be  resolved.  I 


Figure  5:  Thread  interface  from  Example  2. 


3.5  Comparing  Games 

We  now  proceed  to  prove  that  the  strategy  tt*  is  also  a  win¬ 
ning  strategy  for 

Theorem  3.  The  strategy  tv*  is  winning  in  game  G^  ®,  and 
Mn(Gi'®)  =  Win{G^-^). 

Proof.  For  i  e  n}  and  s  €  lTin(G^'®),  we  say 

that  thread  i  is  enabled  in  s  if  there  is  an  edge  (s,  t)  £  E 
such  that  0{s,t)  =  i  and  t  £  Win{G^'^).  Note  that  this 
definition  is  correct,  as  by  Lemma  4  output  edges  are  always 
winning. 

For  i  £  {1, . . . ,  n}  and  s*  €  Win{G^'^),  we  have  to  prove 
that,  using  tv*  in  G^  ®  and  starting  from  s*,  with  positive 
probability  a  state  is  reached  where  thread  i  is  enabled. 
Since  this  is  true  of  every  winning  state  s*,  and  since  the 
game  stays  forever  in  the  set  of  winning  states,  it  follows  that 
the  probability  of  enabling  thread  i  infinitely  often,  ensuring 
that  it  is  also  taken  infinitely  often,  is  in  fact  1. 

If  in  s*  the  next  action  of  thread  i  is  an  output,  then  by 
Lemma  4  it  is  available  directly  from  s*.  Thus,  assume  in  the 
following  that  the  next  action  of  thread  i  in  s*  is  an  input. 
Since  s*  is  winning  in  G^'^,  there  is  a  path  in  Win{G^'^) 
from  s*  to  a  state  t*  where  thread  i  is  enabled.  By  applying 
Lemma  6  to  states  s  =  s*  and  s'  =  G,  we  obtain  that  in 
G^  ®  from  s*  with  positive  probability  a  state  t'  is  reached 
such  that  t*  Gt',  and  therefore  thread  i  is  enabled  in  t'.  I 

The  previous  result,  which  depends  in  a  crucial  way  on  the 
structural  properties  of  G^  ®  (it  is  certainly  not  valid  for 
an  arbitrary  two-person  game),  enables  us  to  compute  in 
quadratic  time  a  winning  strategy  for  game  G^  ®.  We  now 
show  how  to  use  this  result  for  G^  ®  also  for  our  original 
problem  G^. 

Our  first  result  concerns  systems  where  all  resources  are 
mutexes  (called  mutex-only  systems),  and  where  the  threads 
satisfy  the  periodieally  mutex-free  (PMF)  assumption.  Infor¬ 
mally,  this  assumption  states  that,  if  the  intra-thread  non¬ 
determinism  is  resolved  in  a  fair  fashion,  then  the  thread  is 
infinitely  often  not  holding  any  mutex.  In  practice,  threads 
in  mutex-only  systems  invariably  satisfy  the  PMF  assump¬ 
tion.  To  make  this  precise,  consider  a  fixed  thread  inter¬ 
face  li  =  (7?i,  Si,  Ei,  s™‘,  Ai),  for  1  <  i  <  n.  A  path  in 
li  is  a  path  in  the  graph  (Si,  Ei).  We  say  that  an  infinite 
path  is  fair  iff  it  satisfies  /\veOsucc,(u)  ^Ofrom'* 

□  Otafce“’“.  Moreover,  for  a  finite  path  a  and  a  re¬ 
source  X  £  R,  let  decr{x,a)  =  |{(s,t)  G  a  \  \i{s,t)  = 


Figure  6:  Thread  interfaces  from  Example  2. 


Pj;?}|,  incr{x,a)  =  |{(s,t)  G  cr  |  Xi{s,t)  =  and 

balance{x,o)  =  incr{x,a)  —  decr{x,  a).  We  say  that  li  is 
mutex- correct  if  for  all  finite  traces  cr  and  all  mutexes  x  £  Ri, 
it  holds  balance{x,a)  £  {  —  1,0}. 

Definition  7.  We  say  that  a  thread  is  periodically  mutex 
free  (PMF)  if  it  only  uses  mutexes,  it  is  mutex- correct,  and 
in  all  fair  paths  a,  there  exist  infinitely  many  prefixes  a'  of 
a  that  satisfy  balanee{x,a')  =  0  for  all  mutexes  x. 

For  mutex-only  systems  consisting  of  threads  satisfying  the 
PMF  assumption  (called,  for  short,  PMF  systems),  the 
strategy  tv*  is  winning  also  in  G^.  Hence,  for  PMF  sys¬ 
tems  we  can  derive  resource  managers  in  time  quadratic  in 
IG^I. 

Theorem  4.  For  PMF  systems,  tv*  is  winning  in  game  G^ , 
and  Win{G^-^)  =  Win{G^). 

The  next  example  shows  that  tv*  may  not  be  winning  in  G^, 
when  the  system  is  not  PMF.  Notice  that  a  rather  special 
thread  structure  is  required  for  this  to  happen. 

Example  2.  Consider  the  5-mutex,  3-thread  system 
({a,  6,  c,  d,  e},  (7i,  72,  A))  where  7i  is  as  in  Figure  6(a), 

li  is  as  in  Figure  6(b),  and  Is  is  as  in  Figure  5.  First,  at 
all  times  after  thread  1  reaches  state  2,  it  will  always  own 
at  least  one  mutex  among  {a,b,c}.  Similarly,  thread  2  will 
always  own  at  least  one  of  {a,d,e}.  For  this  reason,  the 
system  is  not  PMF.  However,  the  initial  state  (0,0,0,!c°) 
of  G^  ®  is  winning.  Clearly,  threads  1  and  2  can  make 


infinite  progress,  since  they  only  share  mutex  a,  and  they 
both  release  said  mutex  periodically.  It  remains  to  show 
that  under  the  most  general  winning  strategy  rr*,  thread 
3  is  allowed  to  perform  its  critical  region  (i.e.  state  6) 
with  probability  1.  In  ®  (and  G^  ®)  the  nondeterminism 
that  threads  1  and  2  exhibit  in  state  2  is  resolved  by  a 
uniform  distribution.  So,  while  making  infinite  progress, 
with  probability  1  those  threads  will  acquire  mutexes  b 
and  d  at  the  same  time,  thus  leaving  mutexes  c  and  e  free. 
At  that  point,  as  soon  as  mutex  a  is  released,  thread  3 
can  safely  execute  its  critical  region,  by  acquiring  mutexes 
a,  c,  e. 

On  the  other  hand,  in  game  G^  threads  1  and  2  can  coop¬ 
erate  in  order  to  never  release  both  c  and  e  at  the  same  time. 
When  thread  1  is  in  state  2,  thread  2  can  only  be  in  state 
6  or  11  (because  those  are  the  only  states  where  thread  2 
does  not  hold  a).  So,  player  2  can  choose  to  acquire  c  when 
thread  2  is  in  6  (thus  holding  d)  and  acquire  b  when  thread 
2  is  in  11  (thus  holding  e).  This  ensures  that  c  and  e  are 
never  free  at  the  same  time.  Now,  consider  a  state  where  a 
is  free.  Giving  a  to  thread  3  inevitably  leads  to  a  deadlock, 
because  thread  3  needs  c  and  e  before  releasing  a,  and  either 
of  them  is  currently  owned  and  will  not  be  released  before 
a  is.  I 

Our  next  result,  useful  for  threads  that  may  use  semaphores, 
enables  us  to  establish  whether  the  strategy  rr*  is  winning 
also  for  G^.  To  develop  the  result,  note  that  the  game  G^, 
once  player  1  fixes  strategy  tt*  ,  is  a  2-MDP.  For  such  2- 
MDPs,  we  can  compute  in  polynomial  time  the  set  of  win¬ 
ning  states  for  player  2  with  respect  to  the  complementary 
goal  using  an  algorithm  that  is  a  modified  version  of 
the  algorithm  proposed  in  [5]  for  Streett  MDPs.  This  leads 
to  the  following  result. 

Theorem  5.  We  can  check  in  time  0(|G^|^  l^i|) 

whether  the  strategy  tt*  is  winning  in  . 

In  our  experience,  the  strategy  tt*  is  almost  invariably  win¬ 
ning  in  G^;  indeed,  the  only  counterexamples  we  have  been 
able  to  construct  are  based  on  threads  with  fairly  special 
structure,  where  inter-thread  communication  can  be  used 
to  synchronize  the  usage  of  resources  by  threads  in  partic¬ 
ular  ways.  Therefore,  we  claim  that  in  most  cases,  we  can 
construct  a  resource  manager  strategy  in  time  quadratic  in 
IG^I. 

4.  TOWARDS  EFFICIENT  RESOURCE 
MANAGERS 

The  strategy  rr*,  even  when  winning,  may  not  be  an  ef¬ 
ficient  strategy  in  practice.  According  to  it,  the  resource 
manager  would  issue  T  (wait  for  a  resource  request  or  re¬ 
lease)  with  positive  probability  when  there  are  input  moves 
that  are  available  and  winning.  First,  this  potentially  re¬ 
duces  CPU  utilization.  In  fact,  other  things  being  equal,  it 
is  better  to  grant  immediately  as  many  resource  requests  as 
possible:  this  ensures  that  the  OS  scheduler  has  the  widest 
choice  of  threads  to  execute  on  the  CPU,  helping  to  avoid 
idle  time  when  all  available  threads  are  blocked,  e.g.,  waiting 
for  I/O.  More  importantly,  as  a  consequence  of  how  we  ab¬ 
stract  thread  interfaces,  there  is  no  guarantee  that  a  thread 
whose  next  action  is  an  output  will  issue  that  output  within 
a  short  amount  of  time.  For  instance,  the  next  resource  re¬ 
quest  may  be  issued  only  after  some  user  input  has  occurred. 


In  this  section,  we  propose  several  improvements  to  tt*, 
aimed  at  reducing  the  number  of  times  when  the  manager 
issues  T  when  input  actions  are  available. 

Maximal  progress  and  critical  progress  strategies. 

The  simplest  idea  consists  in  issuing  T  only  in  the  states 
s’  =  {s  G  S'  I  7r*(s)(T)  =  1}  where  T  is  the  only  winning 
move:  this  corresponds  to  waiting  for  output  moves  only 
when  no  resource  can  be  granted.  This  idea  leads  to  the 
maximal  progress  strategy  defined  by  7rP(s)  =  (5(T)  for 
s  G  s’,  and  7r^(s)  =  l7niform(Supp(7r* (s))  \  {T})  otherwise. 
Unfortunately,  the  maximal  progress  strategy  is  not  always 
winning,  as  the  following  example  demonstrates. 

Examples.  Consider  the  3-thread  system  ({a,  6},  {a  i— > 
1,6  1},  {Ii,  12,13))  where  7i  and  I2  are  as  in  Figure  7(a), 

while  I3  is  as  in  Figure  7(b).  Figure  7(c)  shows  a  frag¬ 
ment  of  the  corresponding  joint  interface.  Let  us  analyze 
this  fragment  as  part  of  G^,  and  assume  that  player  1  em¬ 
ploys  TT^.  One  can  check  that,  starting  from  the  initial  state 
(0, 0,  0,  iz°),  player  2  can  steer  the  game  to  state  (5, 1, 1,  v), 
where  =  {a  0,  6  1— >  1}.  At  this  point,  all  of  the  edges, 
except  for  the  dashed  ones,  can  be  taken  under  tt*’.  The  ob¬ 
jective  for  the  player  1  is  to  reach  one  of  the  states  labeled  as 
“good” ,  as  in  those  states  thread  3  can  make  progress  with¬ 
out  risking  a  deadlock.  However,  player  2  can  steer  the  game 
away  from  the  two  good  states,  thus  reaching  (1,  5, 1,  iz)  with 
certainty.  Since  (1,5,  l,iz)  is  symmetrical  w.r.t.  (5,  l,l,iz), 
this  strategy  enables  player  2  to  keep  thread  3  starving  for¬ 
ever.  Thus,  TT^  is  not  a  winning  strategy  in  this  game.  The 
same  applies  to  G^'®,  since  the  threads  under  consideration 
have  no  inter-thread  non-determinism. 

It  should  be  noted  that  the  situation  is  different  in  G^'®. 
Since  all  output  edges  happen  uniformly  at  random, 
is  winning  in  this  case,  as  state  (0,0,  l,iz°)  is  eventually 
reached  with  probability  1.  ■ 

The  example  above  suggests  that  sometimes,  as  in  state 
(5,  l,l,iz),  it  is  necessary  to  wait  for  output  actions,  even 
when  there  are  resources  that  are  ready  to  be  granted.  The 
problem  of  waiting  for  outputs,  as  mentioned  earlier,  is  that 
in  general  there  is  no  guarantee  that  the  outputs  will  be 
generated  in  a  timely  fashion.  However,  in  mutex-only  sys¬ 
tems,  we  can  assume  that  when  a  thread  holds  a  mutex  it 
will  generate  an  output  in  a  timely  fashion,  either  to  release 
the  mutex,  or  to  request  another  mutex.  This  captures  the 
idea  that,  in  well-written  code,  critical  regions  have  short 
durations.  Based  on  this  idea,  we  let  5“  be  the  set  of  states 
of  a  mutex-only  system  where  there  is  some  thread  holding 
a  mutex,  and  we  propose  a  strategy  that  waits  for  outputs 
only  in  5'“.  We  define  the  critical  progress  strategy  7r“  by 
letting,  for  all  s  €  S,  7r“(s)  =  ‘^*{s)  if  s  G  5'“  or  s  G  S’,  and 
7r“(s)  =  f7m/orm(Supp(7r*(s))  \  {T})  otherwise.  The  follow¬ 
ing  result  shows  that,  for  PMF  systems,  7r“  is  an  efficient 
resource  manager  strategy. 

Theorem  6.  In  a  PMF  system,  7r“  is  winning  for  . 

Efficient  strategies  for  systems  with  semaphores.  A 

natural  extension  of  7r“  to  systems  with  semaphores  is  a 
strategy  that  waits  for  outputs  only  when  there  is  at  least 
one  thread  waiting  for  a  resource  that  is  not  available  (so 
that  another  thread  must  be  holding  a  resource,  and  it  may 


(a)  (b)  (c) 


Figure  7:  A  system  where  the  maximal  progress 
strategy  is  not  winning. 

be  reasonable  to  expect  an  output  action  in  a  timely  man¬ 
ner).  Unfortunately,  there  are  examples  showing  that  such 
an  extension  is  not  winning  in  general.  We  discuss  two  re¬ 
lated  strategies  that  are  winning,  and  efficient,  for  systems 
with  semaphores. 

To  obtain  our  first  strategy,  we  reason  as  follows.  Once  a 
memoryless  strategy  tt  £  IIi  is  fixed,  the  game  is  equiv¬ 
alent  to  a  2-MDP  G^(rr).  If  an  end-component  in  this  2- 
MDP  is  not  fair,  that  is,  if  there  is  a  thread  k  that  is  neither 
finished,  nor  progresses  in  the  end  component,  then  it  can 
be  seen  that  thread  k  must  be  stuck  waiting  for  an  input 
(a  resource)  at  all  states  of  the  end  component.  This  sug¬ 
gests  to  skip  T  (waiting  for  outputs)  only  when  no  thread 
is  blocked:  in  this  way,  if  the  strategy  differs  from  tv*  by 
cutting  T,  it  can  do  so  only  in  a  winning  component.  Pre¬ 
cisely,  for  s  £  S'  we  let  Succ(s,Tr*)  =  {t  £  S  |  3mi  £ 
ri(s).3m2  £  r2(s).(7r*(mi)  >  0  A  t(s, mi, m2)(t)  >  0)}  be 
the  set  of  possible  successors  of  s  according  to  tt*,  and  we 
let  S*’  =  {s  £  S  I  3fc  £  [l..n].Vt  £  Succ(s,Tr*).0(s,t)  7^  k}  be 
the  set  of  states  where  some  thread  is  blocked.  For  s  £  S, 
we  then  define  by  7r''’(s)  =  7r*(s)  if  s  £  S'^’  U  S',  and 
7r*’(s)  =  l7mform(Supp(7r* (s))  \  {T})  otherwise. 

Theorem  7.  The  strategy  is  winning  in  iffn-*  is  win¬ 
ning  in  G^ . 

Finally,  we  can  obtain  an  efficient  strategy  with  memory  as 
follows.  We  say  that  a  thread  k  is  bypassed  whenever  it  is 
waiting  for  an  input,  and  the  scheduling  strategy  does  not 
give  that  input.  Then,  given  a  bypass  bound  M  £  N,  we 
can  construct  a  strategy  7rJ(f  as  follows.  For  each  thread 
k  £  [l..n],  keeps  track  of  the  number  bk  of  times  for 
which  thread  k  has  been  consecutively  bypassed.  As  long  as 
bk  <  M  for  all  1  <  fc  <  n,  the  strategy  behaves  like 
When  bk  >  M  for  some  k  £  [l..n],  on  the  other  hand, 


reverts  to  behave  like  tt*,  thus  sometimes  waiting  for  outputs 
when  there  are  input  actions  (resource  grants)  that  could 
be  taken.  The  idea,  informally,  is  as  follows:  if  a  thread  is 
bypassed  for  a  large  number  of  consecutive  times,  it  means 
that  some  other  threads  may  be  holding  the  resources  it 
needs  to  proceed.  Favoring  output  actions  (among  which  are 
resource  releases)  enables  the  system  to  reach  a  state  where 
the  bypassed  thread  can  be  finally  granted  the  resource  it 
needs. 

Theorem  8.  For  all  M  £  N,  uie  have  that  is  winning 
in  G^  iff  TT*  is  winning  in  G^ . 

5.  THE  TOOL 

We  have  developed  a  prototype  tool  called  Cynthesis 
that  realizes  the  theory  hereby  presented.  The  tool  takes  as 
input  a  C  program,  and  it  either  produces  a  warning  that 
the  system  is  not  schedulable  (according  to  the  definition 
in  Section  3.2),  or  it  outputs  a  custom  resource  manager 
encoded  as  a  C  program  that  can  be  compiled  and  linked 
to  the  original  program.  The  result  is  an  executable  that 
is  deadlock-free  whenever  the  OS  scheduler  is  fair,  and  the 
threads  do  not  block  for  reasons  other  than  resources  (such 
as  infinite  loops) .  The  tool  is  currently  tailored  to  the  eCos 
embedded  OS  [10],  but  it  can  be  easily  modified  to  work 
with  another  OS. 

To  extract  thread  interfaces,  the  tool  uses  the  OIL  li¬ 
brary  [19]  to  build  a  control-flow  graph  (CFG)  for  each 
thread.  For  the  purpose  of  this  graph,  function  calls  are 
treated  as  inlined.  While  building  the  CFG,  each  time  a 
synchronization  primitive  is  detected,  edges  labeled  with 
the  appropriate  action  are  added  to  the  thread  interface, 
as  follows:  (i)  calls  to  mutex_unlock(x)  and  sem_post(x) 
are  represented  by  an  edge  labeled  rx\,  and  (ii)  calls  to 
mutex_lock(x)  and  sem_wait  (x)  are  represented  by  a  se¬ 
quence  of  two  edges  labeled  with  Wx^-  and  gx'l  respectively. 
The  original  calls  are  also  automatically  annotated  with  lo¬ 
cation  information,  to  allow  the  resource  manager  to  distin¬ 
guish  them  at  run-time.  The  graph  is  then  minimized  to 
remove  transitions  that  do  not  involve  resources. 

Currently,  in  order  for  the  tool  to  correctly  identify  re¬ 
sources,  they  must  be  declared  as  global  variables  and  then 
used  by  their  original  names;  we  are  working  to  add  alias 
analysis  to  the  tool  to  overcome  this  limitation.  Once  the 
thread  interfaces  are  extracted,  the  tool  solves  the  game 
®  and  it  outputs  a  custom  resource  manager  in  the  form 
of  compilable  C  code.  The  resource  manager  behaves  like 
the  strategy  tt*  ,  or  optionally  like  one  of  the  other  winning 
strategies  discussed  in  Section  4.  In  order  to  simulate  the 
behavior  of  a  strategy,  the  custom  manager  needs  to  know 
which  winning  moves  are  available  at  any  given  decision 
point.  In  turn,  this  means  that  it  has  to  know  in  which 
state  of  the  joint  interface  the  system  currently  is,  and  what 
are  the  winning  moves  from  that  state.  Rather  than  keeping 
a  copy  of  the  joint  interface,  which  can  be  of  exponential  size 
in  the  number  of  threads,  the  manager  keeps  separate  copies 
of  the  individual  thread  interfaces,  along  with  the  value  of 
the  resources.  With  this  information,  the  manager  is  aware 
of  all  moves;  all  that  remains  to  encode  are  the  moves  that 
are  not  part  of  the  winning  strategy:  to  do  this,  it  suffices 
to  store  the  set  of  losing  states.  As  the  number  of  losing 
states  can  grow  exponentially  with  the  number  of  threads, 
we  encode  the  losing  states  using  a  BDD  ]2],  leading  to  a 
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[Mil 
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BDD  nodes 

time  (sec.) 

2 

37 

3 

15 

0.05 

3 

171 

18 

30 

0.07 

6 

17496 

2592 

62 

39 

6 

33120 

5490 

211 

334 

Table  1:  Experiments. 


very  compact  representation.  In  Table  1,  we  report  the  re¬ 
sult  of  some  experiments,  all  run  on  a  2.4GHz  Pentium  4 
machine  with  512Mb  of  memory.  The  threads  involved  in 
the  test  give  rise  to  thread  interfaces  having  between  5  and 
12  states;  apart  from  the  resource  primitives,  the  size  of  the 
source  code  of  the  threads  has  a  negligible  effect  on  the  run¬ 
ning  time  of  the  tool,  and  it  is  irrelevant  to  the  size  of  the 
synthesized  manager  and  the  BDD.  The  second  column  re¬ 
ports  the  number  of  states  in  the  joint  interface,  and  the 
last  column  reports  the  total  time  needed  to  synthesize  the 
manager. 

A  Case  Study 

We  conducted  a  more  extensive  test,  consisting  in  analyzing 
a  multi-threaded  program  implementing  an  ad-hoc  network 
protocol  for  Lego  robots.  As  illustrated  in  Figure  8,  the 
program  is  composed  of  five  threads,  represented  by  ovals  in 
the  figure,  that  manage  four  message  queues,  represented  as 
boxes  in  the  figure. 

Threads  user  and  generator  add  packets  to  the  input 
queue.  The  router  thread  removes  packets  from  the  input 
queue,  and  dispatches  them  to  the  other  queues.  Packets 
in  the  user  queue  are  intended  for  the  local  node,  so  they 
are  consumed  by  the  user  thread.  Packets  in  the  broad¬ 
cast  queue  are  intended  for  broadcast,  and  they  are  moved 
to  the  output  queue  by  the  delay  thread,  after  a  random 
delay,  intended  to  avoid  packet  collisions  during  broadcast 
propagations.  Packets  in  the  output  queue  are  in  transit  to 
another  node,  so  they  are  treated  by  the  sender  thread.  No¬ 
tice  that  if  the  sender  fails  to  send  a  packet  on  the  network, 
it  puts  it  in  the  broadcast  queue  (even  if  it  is  not  a  broadcast 
packet),  so  that  it  will  be  re-sent  after  a  delay. 

Each  queue  is  protected  by  a  mutex,  and  two  semaphores 
that  count  the  number  of  empty  and  free  slots,  respec¬ 
tively.  Altogether,  the  program  employs  7  mutexes  and  8 
semaphores.  By  restricting  all  queues  to  having  1  slot,  the 
resulting  joint  interface  contains  400,000  states,  and  the  tool 
terminates  its  analysis  in  about  7  minutes. 

The  tool  found  a  deadlock  that  corresponds  to  the  follow¬ 
ing  situation.  Suppose  that  queues  output  and  broadcast  are 
both  full.  Suppose  also  that  the  sender  thread  extracts  a 
packet  from  output  and  tries  to  send  it  on  the  network.  If 
the  send  fails,  the  thread  will  try  to  insert  the  packet  in  the 
broadcast  queue.  Since  the  latter  is  full,  the  sender  thread 
will  hang  on  a  semaphore,  waiting  for  an  empty  slot  in  broad¬ 
cast.  However,  the  only  way  a  slot  in  broadcast  can  be  emp¬ 
tied  is  for  the  delay  thread  to  move  a  packet  to  output,  which 
is  still  full.  Therefore,  the  sender  will  hang  forever,  and  the 
whole  system  will  consequently  block. 

Interestingly,  the  tool  reports  that  there  is  a  winning 
strategy  in  this  situation.  The  strategy  consists  in  “slow¬ 
ing  down”  the  router,  preventing  it  from  adding  packets  to 
broadcast  if  output  is  full,  and  viceversa. 


Figure  8:  Scheme  of  an  ad-hoc  network  protocol 

implementation. 
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